Vous êtes sans doute sur cette page car vous avez eu un problème pour envoyer du mail à nos abonnés Online.net. Sur cette page, vous trouverez les explications et les solutions à apporter à votre solution de messagerie pour lutter avec nous contre le spam.

Le formulaire suivant vous permettra de vérifier si votre IP est listée chez nous :

La durée de blocage dépend du nombre de spams ou d’erreurs que vous avez généré, la durée maximale du blocage est de 24h. Passé ce delai votre IP sera automatiquement débloquée.

Attention : si votre serveur continue d’essayer d'envoyer du spam vous serez à nouveau bloqué. Il est donc inutile de demander à être déblacklisté tant que le probleme responsable du blocage n'a pas été résolu.

Les décisions de blocages sont prises en se basant sur des statistiques que nous maintenons en temps réel pour chaque IP qui s'est connecté sur nos serveurs MX et sur une analyse des logs. Il est possible, qu'après résolution d'un problême, vous soyez à nouveau blacklisté dans les 24 à 48 heures ; il s'agit là du délai moyen necessaire pour que les anciennes statistiques deviennent négligeables.

Il y a plusieurs raisons qui peuvent nous pousser à bloquer une IP. Pour chacune de ces raisons nos serveurs renvoient des messages d’erreurs différents qui sont listés ci-dessous, vous trouverez ce message d’erreur dans les fichiers de logs de votre serveur SMTP ou dans un DSN que votre relais vous aura renvoyé :

Vous avez cette erreur car votre serveur a envoyé trop de spams au abonnés Online.net, le serveur a donc pris la décision de ne plus accepter les connexions venant de votre serveur SMTP de façon temporaire.

Votre adresse IP sera automatiquement retirée de la liste noire temporaire au bout de 24 heures maximum.

• Si vous avez votre propre serveur SMTP : en attendant l'expiration de ce delai nous vous conseillons de mettre en place un filtre antispam vous permettant de ne plus envoyer/relayer/forwarder de spams vers nos serveurs

• Si vous utilisez un relais SMTP : contacter au plus vite votre prestataire pour qu'il prenne les mesures appropriées pour ne plus etre bloqué à l'avenir.

Vous avez ce message car votre serveur SMTP a généré un nombre d'erreurs trop important lors du dialogue avec les serveurs de Online.net (typiquement des connexions interrompues avant la bonne transmission d'un mail). Il est également possible que le comportement de votre serveur nous laisse l'impression d'être sous le coup d'une attaque dictionnaire (qu'il s'agisse d'envoi de mails ou de validation d'email). Votre IP a donc été bloqué temporairement.

• Si vous avez votre propre serveur SMTP : en attendant l'expiration de ce delai nous vous conseillons de vérifier votre configuration (êtes vous relais ouvert ?). Si vous utilisez la technique “Sender Verify” qui consiste à se connecter sur nos serveurs pour vérifier que le mail from qu'on vous a donné est bien valide nous vous conseillons de désactiver cette fonctionnalité. Il est également possible que votre serveur renvoie des notifications automatiques (mail non délivrable, autorépondeur, etc.) sur du spam. Dans ce cas, il est conseillé de refuser les mails au plus tôt (lors de la reception) pour éviter d'avoir à générer des notifications de mail non délivrable et/ou de s'abstenir de faire des réponses automatique sur les mails qui sont detectés comme étant des spams.

• Si vous utilisez un relais SMTP : contactez au plus vite votre prestataire pour qu'il prenne les mesures appropriées pour ne plus etre bloqué à l'avenir.

Votre IP n'est pas encore bloquée, mais nous n'acceptons plus les mails du fait d'un trop grand nombre d'erreurs. Si votre serveur continue de générer des erreurs vous serez bloqué pour une durée supérieur (et vous aurez une erreur 500).

• Si vous avez votre propre serveur SMTP : en attendant l'expiration de ce delai nous vous conseillons de vérifier votre configuration (êtes vous relais ouvert ?). Si vous utilisez la technique “Sender Verify” nous vous conseillons de la désactiver (analysée par nos serveurs comme une attaque dictionnaire). Il est également possible que votre serveur renvoie des notifications automatiques (mail non délivrable, autorépondeur, etc.) sur du spam. Dans ce cas, il est conseillé de refuser les mails au plus tôt (lors de la reception) pour éviter d'avoir à générer des notifications de mail non délivrable et/ou de s'abstenir de faire des réponses automatique sur les mails qui sont detectés comme étant des spams.

• Si vous utilisez un relais SMTP : contactez au plus vite votre prestataire pour qu'il prenne les mesures appropriées pour ne plus etre bloqué à l'avenir.

Non, nous n'utilisons que des données internes pour bloquer une adresse IP.

24 heures maximum, vous pouvez utiliser cet outil pour voir si votre adresse IP est listée et pour combien de temps.

Historiquement, les mails non sollicités (spams, virus, etc.) étaient principalement une gêne pour les utilisateurs obligés de faire le tri à la main pour séparer le bon grain de l'ivraie. Aujourd'hui, la volumétrie générée par les mails non sollicités est telle qu'elle pose de sérieux problemes techniques sur l'hebergement d'une plateforme mail.

Pour le mois de décembre 2007, une étude a conclu à la présence de 97.13% de mails non sollicités dans les mails reçus. Cela signifie que pour gerer les spams indifférement des mails, il aurait fallu surdimensionner une plateforme mail d'un facteur 34 (33.84 pour être précis) et cela commence à devenir difficilement gérable. Cela impacte l'ensemble des serveurs concernés par l'hebergement mail, qu'il s'agisse de la reception (les serveurs MX), le stockage (aussi bien en terme d'espace de stockage que de la charge en IO) et la retransmission vers les utilisateurs (serveurs POP et IMAP).

Pour les mois de décembre 2006 et décembre 2005, des études équivalentes avaient conclus à la présence d'environ 95% et 90% de spams dans le traffic mail reçu (d'une étude à l'autre, les chiffres varient). La croissance du traffic mail non sollicité progresse peu ou prou deux fois plus vitre que le traffic mail légitime ces dernières années et il est illusoire d'esperer continuer à gérer une plateforme d'hebergement mail un tant soit peu conséquente. Le traffic mail généré par les spams et autres mails non sollicités constituent désormais l'équivalent d'une attaque permanente contre les plateforme d'hebergement mail.

Nous nous sommes donc trouvés dans l'obligation de mettre en place un filtrage dit "antispam". Malheureusement, s'il protege plus ou moins efficacement la partie stockage et délivrance vers les utilisateurs, les serveurs de reception restent sous le feu de la volumétrie et il nous aurait fallu prévoir plus du doublement de leur capacité de reception/filtrage chaque année. Bref, nous continuions d'avoir besoin de dimensionner une partie de l'architecture mail au même rythme que le traffic de mails non sollicités.

Pour finir, la manière dont les spams sont envoyés rendaient nos serveurs MX inaccessibles. En passant majoritairement via des PCs vérolés derrière des connexions “lentes“ (connexions RTC, ADSL, RNIS, etc. de simples utilisateurs ou au travers de connexions internationnales saturées), le temps moyen de connexion s'allonge et les connexions se multiplient en saturant les serveurs. Comme les spammeurs sont également agressifs sur les ouvertures de connexions, non seulement nos serveurs étaient difficilement accessibles mais avec un net déséquilibre en défaveur des serveurs “légitimes“.

C'est pour sortir de ce cercle vicieux que nous avons décidé de bloquer les IPs dont le traffic reçu comportait une part importante de spam (les regles actuelles bloquent lorsque nous recevons plus de mails détectés comme spams que de mails "normaux"), dont le comportement était atypique (nombreuses connexions coupées, nombreux destinataires inexistants, etc.) ou abusif (validation d'adresses mails, mail-bombing, etc.).

Le Sender-Verify consiste, lors de la reception d'un mail, à se connecter sur les serveurs MX de l'emetteur et d'aller vérifier que ce dernier existe bien (ou du moins que le serveur accepte bien un mail à destination de son adresse mail). Il s'agit là d'un mécanisme utilisé habituellement comme filtre antispam. Malheureusement, ce mécanisme nous pose différents problêmes.

Pour commencer un peu d'histoire. Il y a une dizaine d'années, la commande SMTP pour vérifier l'existence d'un email ('VRFY') a été d'un commun accord bloquée dans le cadre de la lutte antispam (pour éviter que les spammeurs puisse valider leurs listes). Il nous semble quelque peu paradoxal de voir resurgir dans le cadre de la lutte antispam le principe de vérification d'une boite mail alors que la commande idoine avait été bloquée dans ce même cadre. Par ailleur et du fait de l'absence de cette commande, Sender-Verify simule l'envoi d'un mail pour récuperer le résultat de la commande 'RCPT TO' (la session étant interrompu avant le début de la transmission du mail). Ceci lui permet de voir si le serveur accepte ou refuse une adresse mail comme destinataire. Si à première vue on pourrait considerer qu'il n'y a pas grande différence entre ces deux commandes, il n'en va pas de même au niveau implémentation. Dans un cas, il suffit de vérifier l'existence de la boite, dans l'autre, nous devons vérifier que le mail sera effectivement délivrable (pour éviter d'envoyer des notifications de non délivrance, nous refusons la reception du mail au plus tôt) et ceci a un surcoût en ressources.

Sur un point de vue technique, il ne nous est pas possible de différencier une requete de type Sender-Verify qu'elle provienne d'un spammeur désireux de valider sa liste ou d'un serveur souhaitant vérifier que l'emetteur d'un mail existe bien. Si, à première vue, il peut paraitre souhaitable de pouvoir valider l'existence d'une adresse mail pour rejeter un courier dont l'emetteur n'existerait pas (donc probablement du spam), faire porter à un tiers le coût de ce filtre ne nous semble ni respectueux pour les ressources de celui-ci (alors que les spams représentent la quasi-totalité du traffic et que le domaine usurpé n'a probablement rien à voir avec le spam en question) ni judicieux (dans le cas où il y aurait un spam massif qui usurperait un domaine bien précis, les serveurs en vérifiant les emetteurs risquent fort de participer à l'insu de leur plein gré à une attaque de type DoS à l'encontre du domaine).

De plus, ce filtre est facilement contournable. Il suffit au spammeur d'utiliser une liste d'adresse mail valides pour l'envoi de ses spams. Certains l'utilisent déjà très certainement : certains de nos abonnés se plaignent de recevoir des DSN par centaines (voir milliers).

S'il est normal d'informer un utilisateur que son mail n'a pu être transmis à son destinataire ou que untel est en congé, il ne faut pas non plus en envoyer à tort et à travers. Alors que le traffic mail est composé dans sa quasi-totalité de spams (dont les emetteurs sont usurpés), envoyer une notification automatique est un exercice périlleux car les risques d'envoyer un mail non sollicité sont elevés (si l'emetteur est usurpé, la notification est envoyé à un destinataire qui n'a strictement rien demandé et se transforme donc en mail non sollicité au même titre que les spams). Il est donc souhaitable de refuser au plus tôt un mail (typiquement lors du dialogue SMTP sur le 'RCPT TO' dans le cadre où un destinataire serait inexistant ou ne pourrait recevoir de mail, sur la fin du 'DATA' dans le cas où vous décideriez de refuser le mail) voir s'abstenir d'envoyer de notification automatique si le mail semble être un spam. Ceci aurait en plus l'interet de réduire sensiblement le traffic mail puisque les spammeurs s'abstiennent généralement d'emettre des notifications lors des refus. Si les RFCs sont relativement peu verbeuses sur le sujet, on peut néanmoins y trouver les recommandations suivantes :

• RFC 2505 :

1.5. Where to block spam, in SMTP, in RFC822 or in the UA

Our basic assumption is that refuse/accept is handled at the SMTP layer and that an MTA that decides to refuse a message should do so while still in the SMTP dialogue. First, this means that we do not have to store a copy of a message we later decide to refuse and second, our responsibility for that message is low or none - since we have not yet read it in, we leave it to the sender to handle the error.

• RFC 3834 :

2. When (not) to send automatic responses

An automatic responder MUST NOT blindly send a response for every message received. In practice there are always reasons to refuse to respond to some kinds of received messages, e.g., for loop prevention, to avoid responding to "spam" or viruses, to avoid being used as a means to launder or amplify abusive messages, to avoid inappropriately revealing personal information about the recipient (e.g., to avoid an automatic indication that a recipient has not read his mail recently), and to thwart denial-of-service attacks against the responder. The criteria for deciding whether to respond will differ from one responder to another, according to the responder's purpose. In general, care should be taken to avoid sending useless or redundant responses, and to avoid contributing to mail loops or facilitating denial-of-service attacks.

SMTP (Simple Mail Transfer Protocol) est le protocole qui permet l'échange de mails. Un serveur SMTP est un logiciel permettant le réception et/ou l'envoi de mails.

Un DSN (Delivery Status Notification) est un mail généré par un serveur SMTP lorsqu'il n'arrive pas à envoyer un mail. Il envoie ce mail pour prévenir l'utilisateur que le mail n'a pas pu être délivré. Ce mail contient toutes les informations sur la transaction SMTP.

C'est une erreur qu'un serveur SMTP renvoie à la commande “RCPT TO” lorsque l'adresse mail que vous cherchez à joindre n'existe pas. De nombreux spammeurs générent ce type d'erreur en faisant des spams par dictionnaire.